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Abstract 


In Proxy Mobile IPv6, packets received from a Mobile Node (MN) by the 
Mobile Access Gateway (MAG) to which it is attached are typically 
tunneled to a Local Mobility Anchor (LMA) for routing. The term 
"localized routing" refers to a method by which packets are routed 
directly between an MN’s MAG and the MAG of its Correspondent Node 
(CN) without involving any LMA. In a Proxy Mobile IPv6 deployment, 
it may be desirable to control the establishment of localized routing 
sessions between two MAGs in a Proxy Mobile IPv6 domain by requiring 
that the session be authorized. This document specifies how to 
accomplish this using the Diameter protocol. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7156. 
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Les 


Introduction 


Proxy Mobile IPv6 (PMIPv6) [RFC5213] allows the Mobile Access Gateway 
(MAG) to optimize media delivery by locally routing packets from a 
Mobile Node (MN) to a Correspondent Node (CN) that is locally 
attached to an access link connected to the same Mobile Access 
Gateway, avoiding tunneling them to the Mobile Node’s Local Mobility 
Anchor (LMA). This is referred to as "local routing" in RFC 5213 
[RFC5213]. However, this mechanism is not applicable to the typical 
scenarios in which the MN and CN are connected to different MAGs and 
are registered to the same LMA or different LMAs. [RFC6279] takes 
those typical scenarios into account and defines the problem 
statement for PMIPv6 localized routing. Based on the scenarios A11, 
A12, and A21 described in [RFC6279], [RFC6705] specifies the PMIPv6 
localized routing protocol that is used to establish a localized 
routing path between two Mobile Access Gateways in a PMIPv6 domain. 


This document describes Authentication, Authorization, and Accounting 
(AAA) support using Diameter [RFC6733] for the authorization 
procedure between the PMIPv6 mobility entities (MAG or LMA) and a AAA 
server within a Proxy Mobile IPv6 domain for localized routing in the 
scenarios All, A12, and A21 described in [RFC6279]. 


Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Solution Overview 


This document addresses how to provide authorization information to 
the Mobile Node’s MAG or LMA to enable localized routing and resolve 
the destination MN’s MAG by means of interaction between the LMA and 
the AAA server. Figure 1 shows the reference architecture for 
Localized Routing Service Authorization. This reference architecture 
assumes that 


o If the MN and CN belong to different LMAs, the MN and CN should 
share the same MAG (i.e., scenario A12 described in [RFC6279]), 
e.g., MN1 and CN2 in Figure 1 are attached to MAG1 and belong to 
LMA1 and LMA2, respectively. Note that LMA1 and LMA2 in Figure 1 
are in the same provider domain (as described in [RFC6279]). 


o If the MN and CN are attached to different MAGs, the MN and CN 
should belong to the same LMA (i.e., scenario A21 described in 
[RFC6279]); for example, MN1 and CN3 in Figure 1 are attached to 
MAG1 and MAG3, respectively, but belong to LMA1. 
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o The MN and CN may belong to the same LMA and may be attached to 
the same MAG (i.e., scenario All described in [RFC6279]), e.g., 
MN1 and CN1 in Figure 1 are both attached to the MAG1 and belong 
to LMA1. 


o The MAG and LMA support Diameter client functionality. 


4--------- + 
e—a > AAA & 
| +------ >| Policy 
| | | Profile | 
| Diameter +--------- + 
| 
| +--V-+ f----+ 
| $------- >| LMA | | LMA2 | 
+---++ +---—--+ 
| | | | 
Diameter | | +------- i; | 
| | | 
| PMIP | | \\ 
| | // // \\ 
| | // // \\ 
// def \\ 
| | | | | 
| 4+---->4--------------- + 4+----+ 
| | MAG1 | | MAG3 | 
f-------- >4--------------- + f----+ 
+---+ +---+ ee +—---+ 
|MN1| |cN1] |CN2| | CN3 | 
fo--$  F---4+ 0 FH--+ +---+4+ 


Figure 1: Localized Routing Service Authorization Reference 
Architecture 


The interaction of the MAG and LMA with the AAA server according to 
the extension specified in this document is used to authorize the 
localized routing service. 

4. Attribute Value Pair Used in This Document 
This section describes Attribute Value Pairs (AVPs) and AVP values 


defined by this specification or reused from existing specifications 
in a PMIPv6-specific way. 
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4.1. User-Name AVP 


The User-Name AVP (AVP Code 1) is defined in [RFC6733], Section 8.14. 
This AVP is used to carry the Mobile Node identifier (MN-Identifier) 
[RFC5213] in the Diameter AA-Request message [RFC7155] sent to the 
AAA server. The MN-Identifier is defined in PMIPv6 [RFC5213]. 


4.2. PMIP6-IPv4-Home-Address AVP 


The PMIP6-IPv4—-Home-Address AVP (AVP Code 505) is defined in 
[RFC5779], Section 5.2. This AVP is used to carry the Mobile Node’s 
IPv4 home address (IPv4-MN-HoA) in the Diameter AA-Request message 
[RFC7155] sent to the AAA server. The IPv4-MN-HoA is defined in 
[RFC5844]. 


4.3. MIP6—-Home-Link-Prefix AVP 


The MIP6-Home-Link-Prefix AVP (AVP Code 125) is defined in [RFC5779], 
Section 5.3. This AVP is used to carry the Mobile Node’s home 
network prefix (MN-HNP) in the Diameter AA-Request [RFC7155] sent to 
the AAA server. 


4.4. MIP6-Feature-Vector AVP 


The MIP6-Feature-Vector AVP is defined in [RFC5447] and contains a 
64-bit flags field used to indicate supported capabilities to the AAA 
server. This document allocates a new capability flag bit according 
to the IANA rules in RFC 5447 [RFC5447]. 


INTER_MAG_ROUTING_SUPPORTED (0x0002000000000000) 


When set, this flag indicates support or authorization of Direct 
routing of IP packets between MNs anchored to different MAGs 
without involving any LMA. 


During the network access authentication and authorization procedure 
[RFC5779], this flag is set by the MAG or LMA in the MIP6-Feature- 
Vector AVP included in the request to indicate to the home AAA server 
(HAAA) that inter-MAG direct routing may be provided to the mobile 
node identified by the User-Name AVP. By setting the 

INTER_MAG ROUTING_SUPPORTED flag in the response, the HAAA indicates 
to the MAG or LMA that direct routing of IP packets between this 
mobile node and another node anchored to a different MAG is 
authorized. The MAG and the LMA set also the 

INTER_MAG ROUTING_SUPPORTED flag of the MIP6-Feature-Vector AVP in 
AA-R sent to the HAAA for requesting authorization of inter-MAG 
direct routing between the mobile nodes identified in the request by 
two distinct instances of the User-Name AVP. If this bit is set in 
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the returned MIP6-Feature-Vector AVP, the HAAA authorizes direct 
routing of packets between MNs anchored to different MAGs. When the 
INTER_MAG ROUTING_SUPPORTED flag is cleared, either in request or 
response, it indicates that the procedures related to authorization 
of localized routing between MNs anchored to different MAGs is not 
supported or not authorized. MAG and LMA compliant to this 
specification MUST support this policy feature on a per-MN and per- 
subscription basis. 


5. Example Signaling Flows for Localized Routing Service Authorization 


Localized Routing Service Authorization can happen during the network 
access authentication procedure [RFC5779] before localized routing is 
initialized. In this case, the preauthorized pairs of LMA / prefix 
sets can be downloaded to Proxy Mobile IPv6é entities during the 
procedure from [RFC5779]. Localized routing can be initiated once 
the destination of a received packet matches one or more of the 
prefixes received during the procedure from [RFC5779]. 


Figure 2 shows an example scenario in which MAG1 acts as a Diameter 
client, processing the data packet from MN1 to MN2 and requesting 
authorization of localized routing (i.e., MAG-Initiated LR 


authorization). In this example scenario, MN1 and MN2 are attached 
to the same MAG and anchored to the different LMAs (i.e., scenario 
A12 described in [RFC6279]). In this case, MAG1 knows that MN2 


belongs to a different LMA (which can be determined by looking up the 
binding cache entries corresponding to MN1 and MN2 and comparing the 
addresses of LMA1l and LMA2). In order to set up a localized routing 
path with MAG2, MAG1 acts as Diameter client and sends an AA-Request 
message to the AAA server. The message contains an instance of the 
MIP6-Feature-Vector (MFV) AVP [RFC5447] with the 

LOCAL_MAG ROUTING_SUPPORTED bit ([RFC5779], Section 5.5) set, two 
instances of the User-Name AVP [RFC6733] containing the identifiers 
of MN1 and MN2. In addition, the message may contain either: 


- an instance of the MIP6-Home-Link-Prefix AVP [RFC5779] carrying the 
MN1’s IPv4 address; 


- an instance of the PMIP6-IPv4-Home-Address AVP [RFC5779] carrying 
the MN1’s home network prefix (MN-HNP). 


The AAA server authorizes the localized routing service by checking 
if MN1 and MN2 are allowed to use localized routing. If so, the AAA 
server responds with a AAA message encapsulating an instance of the 
MIP6-Feature-Vector (MFV) AVP [RFC5447] with the 

LOCAL_MAG_ ROUTING_SUPPORTED bit ([RFC5779], Section 5.5) set 
indicating that direct routing of IP packets between MNs anchored to 
the same MAG is authorized. MAG1 then knows that the localized 
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routing between MN1 and MN2 is allowed. Then, MAG1 sends the Request 
messages respectively to LMA1 and LMA2. The request message is the 
Localized Routing Initialization (LRI) message in Figure 2 and 
belongs to the Initial phase of the localized routing. LMA1 and LMA2 
respond to MAG1 using the Localized Routing Acknowledge message (LRA 
in Figure 2) in accordance with [RFC6705]. 


In case of LRA_WAIT_TIME expiration [RFC6705], MAG1 should ask for 
authorization of localized routing again according to the procedure 
described above before the LRI is retransmitted up to a maximum of 
LRI_RETRIES. 


+--+ 4+---+ 4+----+ 4+----+ 4+---+ 4+----+ 
| MN2 | | MN1 | |MAG1 | | LMA1 | | AAA | | LMA2 | 
+-|-+ +-+-+ +-+--+ +-+--+ +-+-+ +-+--+ 

| | Anchored | | | 

O a a a eee e E o 

| | Anchored | | | 

| 0------------------ 0 | | 

| Data [MN1->MN2] | | | 

| |------- >| | | | 

| | | AA-Request (MFV, MN1,MN2) | 

Bas es Sa ee eS >| 

| | | AA-Answer (MFV) | | 

| | e E nen | | 

| | | IRI | | | 

| | |-------- >| | | 

| IRI | 
ENEE a ee et EE E > 

| | | IRA | | | 

| | |<-------- | | | 

| | | | IRA | | 

| | [See peo ero as = ero e | 


Figure 2: MAG-Initiated Localized Routing Authorization in A12 


Figure 3 shows the second example scenario, in which LMA1 acts as a 
Diameter client, processing the data packet from MN2 to MN1 and 
requesting the authorization of localized routing. In this scenario, 
MN1 and MN2 are attached to a different MAG and anchored to the same 
LMA (i.e., A21 described in [RFC6279]), LMA knows that MN1 and MN2 
belong to the same LMA (which can be determined by looking up the 
binding cache entries corresponding to MN1 and MN2 and comparing the 
addresses of the LMA corresponding to MN1 and LMA corresponding to 
MN2). In contrast with the signaling flow shown in Figure 2, it is 
LMA1 instead of MAG1 that initiates the setup of the localized 
routing path. 
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The Diameter client in LMA1 sends an AA-Request message to the AAA 
server. The message contains an instance of the MIP6-Feature-Vector 
(MFV) AVP [RFC5447] with the INTER_MAG ROUTING_SUPPORTED bit 
(Section 4.5) set indicating direct routing of IP packets between MNs 
anchored to different MAGs is supported and two instances of the 
User-Name AVP [RFC6733] containing identifiers of MN1 and MN2. The 
AAA server authorizes the localized routing service by checking if 
MN1 and MN2 are allowed to use localized routing. If so, the AAA 
server responds with an AA-Answer message encapsulating an instance 
of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the 

INTER_MAG ROUTING_SUPPORTED bit (Section 4.5) set indicating that 
direct routing of IP packets between MNs anchored to different MAGs 


is authorized. LMA1 then knows the localized routing is allowed. In 
a successful case, LMA1 responds to MAG1 in accordance with 
[RFC6705]. 


In the case of LRA_WAIT_TIME expiration [RFC6705], LMA1 should ask 
for authorization of localized routing again according to the 
procedure described above before the LRI is retransmitted up to a 
maximum of LRI_RETRIES. 


+---+ +----+ +----+ +---+ +----+  +---+ 

| MN1 | |MAG1| |ZLMA1| | AAA | |MAG2 | | MN2 | 

+-+-+ +-+--+ +-+--+ +-+-+ +-+--+  +-+-+ 

| | | Anchored | | 

| Anchored OEE E E E PeSesa SS O 

o-------- +------- o Data[MN2->MN1] | | 
<---—- | | 

AA-Request (MFV,MN1,MN2) | 

| | |--------- >| | | 

| | |AA-Answer (MFV) | | 

| | unr |<--------- | | 

| |<------| LRI | | 
LRA |------------------ > 

OO e | 

| | |<------------------ | | 


Figure 3: LMA-Initiated Localized Routing Authorization in A21 


Figure 4 shows another example scenario, in which LMA1 acts as a 
Diameter client, processing the data packet from MN2 to MN1 and 
requesting the authorization of localized routing. In this scenario, 
MN1 and MN2 are attached to the same MAG and anchored to the same LMA 
(i.e., All described in [RFC6279]), the LMA knows that MN1 and MN2 
belong to the same LMA (which can be determined by looking up the 
binding cache entries corresponding to MN1 and MN2 and comparing the 
addresses of LMA corresponding to MN1 and LMA corresponding to MN2). 
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The Diameter client in LMAl1 sends an AA-Request message to the AAA 
server. The message contains an instance of the MIP6-Feature-Vector 
AVP [RFC5447] with the LOCAL_MAG ROUTING_SUPPORTED bit set and two 
instances of the User-Name AVP [RFC6733] containing the identifiers 
MN1 and MN2. The AAA server authorizes the localized routing service 
by checking if MN1 and MN2 are allowed to use localized routing. If 
so, the AAA server responds with an AA-Answer message encapsulating 
an instance of the MIP6-Feature-Vector (MFV) AVP [RFC5447] with the 
LOCAL_MAG ROUTING_SUPPORTED bit ([RFC5779], Section 5.5) set 
indicating that direct routing of IP packets between MNs anchored to 
the same MAG is authorized. LMA1 then knows the localized routing is 
allowed and responds to MAG1 for localized routing in accordance with 
[RFC6705]. 


In the case of LRA_WAIT_TIME expiration [RFC6705], LMA1 should ask 
for authorization of localized routing again according to the 
procedure described above before the LRI is retransmitted up to a 
maximum of LRI_RETRIES. 


+---+ +---+ +----+ +----+ 4+---+ 
|MN2| |MN1| |MAG1| |LMA1| | AAA | 
+-+-+ +-+-+ +-+--+ +-+--+ +-|-+ 

| | Anchored űć | 

O a E aS o | 

| | Anchored űć | | 

| o-------- +------- o Data[MN2->MN1] 

| | | ene | 

| | | AA-Request tie MN1,MN2) 

-—-------- > 

| | | | AA-Answer (MFV) 

| | | art |<--------- | 

| | |<------| | 

| | | LRA | | 

| | |------>| | 


Figure 4: LMA-Initiated Localized Routing Authorization in A11 
6. Security Considerations 
The security considerations for the Diameter Network Access Server 
Requirements (NASREQ) [RFC7155] and Diameter Proxy Mobile IPv6 
[RFC5779] applications are also applicable to this document. 
The service authorization solicited by the MAG or the LMA relies upon 


the existing trust relationship between the MAG/LMA and the AAA 
server. 
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10. 


10. 


An authorized MAG could, in principle, track the movement of any 
participating mobile nodes at the level of the MAG to which they are 
anchored. If such a MAG were compromised, or under the control of a 
bad actor, then such tracking could represent a privacy breach for 
the set of tracked mobile nodes. In such a case, the traffic pattern 
from the compromised MAG might be notable, so monitoring for, e.g., 
excessive queries from MAGs, might be worthwhile. 


IANA Considerations 
This specification defines a new value in the "Mobility Capability 
Registry" [RFC5447] for use with the MIP6-Feature-Vector AVP: 
INTER_MAG ROUTING_SUPPORTED (see Section 4.4). 
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